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Management summary 


“It is not the strongest of the species that survive, nor the most intelligent, but the 
one most responsive to change.”! 


Setting the scene Goal of this Point of View 
In the current world of IT and the development of This point of view aims to create awareness around the 
IT-related products or services, companies from transformation towards the DevOps way of working, to 
enterprise level to smaller sizes are starting to help gain understanding what DevOps is, why you need it 
use the DevOps processes and methods as a part and what is needed to implement DevOps. 
of their day-to-day organization process. 
The goal is to reduce the time involved in all the An Enterprise Architecture perspective 


software development phases, to achieve greater 


application stability and faster development Even though it is DevOps from an Enterprise Architecture 


service line perspective, this material has been gathered 


cycles. . . from our experiences with customers, combined with 
However not only on the technical side of the knowledge from subject matter experts and theory from 
organization is DevOps changing the playing within and outside Deloitte. 


field, also an organizational change that involves 
merging development and operations teams is 
required with an hint of cultural changes. 


And last but not least the skillset of all people It is specifically for the people within Deloitte that want to 

involved is changing. use this as an accelerator for conversations and proposals 
& to get in contact with the people who have performed 
these type of projects. 


Targeted audience 


By all means, it is a deck that can be shared within 
Deloitte and with our customers to provide a more holistic 


1 Charles Darwin View. 
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What is DevOps? 
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What is DevOps? 


DevOps is a new way-of-working that improves value delivery for the customer and 
enables benefits for both development and operations 
Definition 


Software Delivery 
Lifecycle 


DevOps primary goal is to improve the flow 
from an idea towards value for the customer, 


DevOps is a new approach to optimize and 
manage end-to-end service delivery and 


operations. It applies a set of principles to 
transform the entire software delivery lifecycle 
to introduce new practices enabled by 
technology 


CP >» enabled by an environment in which 
multidisciplinary teams work collaboratively to 
Dev Ops ' ; ; 
continuously deliver high quality solutions, in a 
J »> faster pace, that qualify for operations 


New DevOps practices: 


DevOps principles * Continuous Integration Benefits 
* Continuous Testing 
¢ Culture of shared responsibility ~ Conti Deli * Increases the frequency and 
and collaboration ene US vel quality of deployments and 
* Continuous Operations releases 


¢ End-to-end ownership of services 
* Multi-disciplinary teams * Improves innovation and risk- 


| k= i=» ine 
> Deicpenicntay Nave Geively * Realizes faster time to market 


Flow eputnization in tne delvery Applying DevOps principles * Improves solution quality and 
process to the SDLC lead to new operational reliability 

* Automate (almost) everything practices that benefit both - Improves the Mean Time to 

- Measurement of everything Development and Operations Recover (MTTR) 


¢* Continuous improvement 
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The History of DevOps 


DevOps is becoming the norm in software delivery and is increasingly being adopted & 
matured across enterprises, becoming the new best practice 


The chronic conflict 
between Dev & Ops is 
explored 


2008 Based on personal experience 
living in the world of Dev and 


Ops, Patrick Debois from 


Belgium starts investigating 
the chronic conflict between 


Dev and Ops. 


Pre-DevOps 


Pre- \ In17, traditional 

2008 | waterfall methods of 
application 
development were 
losing ground to 
iterative methods such 
as agile. Speed 
became the goal, 
which took priority 
over development and 
deployment processes. 
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The grass roots movement 


takes off 


DevOps expands upon the 


practices of “infrastructure as 
code” and continuous integration 


and deployment. DevOps principles 


stream. 


The “DevOps” term is 
coined 

Andrew Shafer and Patrick 
Debois meet at the 
DevOpsDays 2009 and later 
at Velocity conference, the 
term is picked up: 


"10+ Deploys a Day - a 
collaboration between Dev 
& Ops at Flickr” - Velocity, 
2009. 


start being applied to the IT value 


“DevOps is the 
future” 

March 2011, Gartner 
predicts “By 2015 
DevOps will be adopted 
by 20% of the Fortune 
2000.” 


Most CIOs and IT 
organizations are looking 
into doing work 
differently. 


incorporated into 


SAFe is rapidly gaining 
traction in the enterprise 
arena, where DevOps is 
adopted and scaled 


DevOps is the 
new norm for 
high-performing 
companies 
“Clearly, what was 
state of-the-art three 
years ago is just not 
good enough for 
today’s business 
environment.” 


p.18, 2016 State of 
DevOps Report 


State of DevOps 
report defines 5- 
stage approach 
From level 0 to 5, a 
descriptive, pragmatic 
approach is introduced 
to guide teams and 
mature DevOps 
initiatives, a report 
sponsored by Deloitte 


Enterprises embed 
more IT functions 
in their teams next 
to ‘Dev’ and ‘Ops’ 
“organizations are 
embedding security 
(DevSecOps), privacy, 
policy, data (DataOps) 
and controls into their 
DevOps culture and 
processes.” 


Deloitte Tech Trends 
2019 
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DevOps practices 


DevOps practices apply continuous automation cycles throughout software 
development and operations processes 


Continuous Integration Continuous Delivery 


the streamlining of internal 

GQ development by integrating 
code into a shared 

</> repository several times a 

day. Each check in is then 
verified by an automated 
build, allowing teams to 
detect problems early in 
the cycle 


is the process of delivering 
code that is production 
ready and is kept in an 
always releasable state, so 
it can be deployed 
(automatically) to 
production at any given 
time based on business 
needs 


Software Delivery Lifecycle Process 


Development Operations 


Continuous Testing Continuous Operations 


=== automating and integrating is proactively managing the 
tests into the software solution based on feedback 


delivery chain, and loops. Monitoring and 
automatically executing telemetry become part of 
those tests against each the backlog. Processes 
build of the code base such as patching also fall 


under this practice 
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Why do I need DevOps? 


Traditional function separation for Development and Operations 


Prior to DevOps change release frequency was low, Development and Operations 
worked separately to serve business demands, having completely opposite mindsets 


Business 


Request Demand @) 
features Stability 
Operations 
Safeguards Stability 


\) 
a 1. Focusses solely on operational activities 
in ve 

Usets in the 4© 
2. Operational requirements are unclear between = 2. Operational requirements are unclear, needing 
environments making the hand-over cumbersome ad-hoc changes to the environment 
3. Operational feedback is only retrieved after _ 3. Operational understanding and experience is 
completing a release gained only when the app is released 
4. After releasing, developers are no longer 4. Operators manage and control software 
involved written by others 


Development 
hanges Features 
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DevOps unifies the mindset of Development and Operations 


Today business wants to release on demand. With DevOps, both functions continuously 
collaborate to align business demands within the software delivery lifecycle 


Business 


Request Demand 
features Stability 


Development Operations 
Changes Features Safeguards Stability 


End-to-end management and 
traceability of software 
delivery during development 
and issue solving 


The DevOps culture emphasizes 
a common goal over the 
whole value delivery chain 


IT governance (e.g. security) 
is embedded within the 
software development best 
practices 


All members understand 
change, are responsible and 
accountable as a whole, and 
trust each other to deliver 


Integrated software testing 
approach to validate code 
quality earlier in the process 


The DevOps technology 
embraces CI/CD to automate 
the broken delivery funnel 
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Where ts DevOps applicable? 


Indicators for DevOps Applicability 
Several indicators help to determine if DevOps is applicable for your organization 


DevOps is DevOps is 
Applicable Not Applicable 
Management trusts delivery teams to work Management requires direct involvement in the 
autonomously and only shares a product vision Leadership style delivery process and makes all decisions 


Multiple teams are responsible to manage the end- Product or service delivery does not require a multi 
to-end lifecycle of a single product Team composition disciplinary (cross-functional) team 
Environments where IT solutions are changing Change rate Environments where IT solutions have low change 
rapidly Change rate ecitic 


: . Your delivery process has many sequential 
An InGreMmental Gcuvery apnea Hiab rosuses oh Delivery process constraints, where outputs equal required inputs for 
early value delivery ; 
consecutive process steps 


Desired product end-state is unknown, changing 


. . : : : F . Desired product end-state is known and business 
business requirements give guidance on steering Business uncertainty : 
development requirements do not often change 


mi ™ 
People have great affinity with software and People have no affinity for new technologies, and 
technology and are not change averse Change willingness are change averse 
, , oa = = Products are tangible, typically consisting of semi- 
Product is software peas be delivered as-a Product type finished products provisioned by multiple partners 


that don’t have a direct relation with each other 
Indicator 
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What ts needed for DevOps to work? 


DevOps dimensions 


The DevOps operating model is structured along People, Process and Technology, each 
dimension is necessary for successful DevOps 


} 
Process 


Establish standardized interconnected process in 
the software development (and operation) 
lifecycle 


* Continuous Everything: integration, delivery, 
testing, monitoring, release management and 
planning 


* Continuous Integration and Continuous 
Delivery are key to build quality into DevOps 
processes 


¢ Establish interconnected processes across all 
phases of development and operations for 
consistent and predictable deployments 
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Operating 


Model 


Establish a DevOps Organization & Culture with cross-functional teams that are 
open and trustful 


T-shaped employees 


Foster continuous learning and development to build cross functional capabilities 
and a mindset open to continuous change 


Transformational leadership & balanced metrics to drive DevOps culture 


Open and transparent communication enable feedback and short learning cycles 


o 
Technology 


Improve toolset to support the delivery and 
automation of the process specifically to 
accelerate software delivery activities 


* Container based delivery and immutable 
infrastructure blocks 


¢ Leverage the vast DevOps tooling landscape to 
automate and support Continuous Integration 
and Continuous Delivery and minimize user 
intervention 


* Support of dynamic environment configuration 
to help remediate the current bottleneck in 
testing environment availability 


Operating Model & 


¢ People, Process and Technology 
combined in a governance model for 
the DevOps way-of-working 


* Teams deliver services end-to-end in 
the DevOps Target Operating Model 
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People 
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DevOps Organization & Culture An 


The principles of the DevOps way-of-working have extensive implications on the 
Organization structure, as well as on the culture of the workforce 


DevOps principle Implication for Organization & Culture 


Culture of shared Teams are accountable for progress and output, not an individual team member. Team setup is persistent and co- 
responsibility and collaboration located to improve collaboration and performance. 


End-to-end ownership of Team resources are allocated by services instead of organizational functions. Teams take end-to-end accountability 
services and responsibility (vertically integrated) for the delivery of a service. 


Teams are setup vertically, end-to-end responsible for the whole lifecycle of a product. It contains balanced T- 


J AML etek PANS GE ne shaped skilled personnel from various domains (cross-functional) to achieve its targets. 


Incremental value delivery Work is broken down into small pieces to continuously deliver value to the business using iterative and frequent 


releases. 
Flow optimization in the Elimination of waste, shift left and limit work in progress optimizes the flow in the delivery process. Teams test as 
delivery process early and as often as possible, minimize handoffs and maximize checkpoints to reduce dependencies and risks. 


Tools automate as many tasks and process steps as possible in the delivery process to drastically reduce time, 


Automate (almost) everything effort, and risk of human errors. 


Everything is monitored and measured by a balanced metric system focused on the speed and stability of service 


Measurement of everything delivery 


Teams organize retrospectives, (automated) feedback loops, and touchpoints with the business in order to 


Sonn OUS MPEG vement continuously improve their delivery and way-of-working. 
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ooo 


DevOps principles are the starting point for an organization structure Ane 
Based on DevOps principles, an organization allocates resources by service instead of 


functions to enable end-to-end ownership and increase agility within teams 


DevOps principles 


Culture of shared 
responsibility and collaboration 


Product/Service multi- 
disciplinary team(s) are aligned to 
a particular service 


Product Owner a fixed business 


Service A Service B 


Tech Lead is a product team 
member with extensive technical 
development experience who can 
lead the Product Team in the 
execution of its work 


, F resource empowered to shape and F ional p Sa5 
End-to-end ownership of services discethe seceeoea Me a esis ) Functional Communities of 
. . , ~~ «L| | DevOps | |__| | DevOps; | ___ Practices are the knowledge 
product in a way that maximizes Sei 4 ie 
as Bueinceswulue=—=(“‘ésD*”*#*«( Re, DO omic -secesentebes sharing and communication glue 
Multi-disciplinary teams Functional | that keeps functional expertise 
CoPs ! (e.g. QA, development, testing 
ley eerie ee “Cictean> MM tesco foo etc.) together 
Incremental value delivery Cross Functional DevOps team = ——etem* | {pp 
is a long-standing, fully-allocated, eunckonal: 
oo - cross functional team that is end- si oes : 
Flow optimization in the delivery to-end responsible for (a module = +| | CEVMPS ff 


process 


Automate (almost) everything 


Measurement of everything 


of) the delivered product 


Common Core services are 


= Solutions cs Solutions 
Architect Architect 


Common Core services 


Solution Architect is a product 
team member who governs 
architecture, design and 
implementation while enforcing 
architecture standards and 


shared services provided, ee 
preferably through self-service guidelines 
; : portals, by teams of the 
Continuous improvement technology organization to be 
used by the different DevOps 
teams 
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Key DevOps roles and responsibilities An 


Several key roles should be represented in a cross functional DevOps team; a team 
member with a T-shaped profile can fulfill more than one role 


The DevOps Engineer writes and 
Service A Service B verifies code, fixes bugs, executes 
patch management, maintains 


- asset and configuration repository 
| 7 The Business Analyst and functions as 2" line support The Test Engineer creates and 


engages the business for executes test scripts, automates 
requirements, helps defining \~ vy tests, supports usability testing & 
features, user stories & test W UAT, and manages test 

cases, and validates designs environments and test data 


CoPs 


CoPs 


Functional 
CoPs 


2 Solutions = Solutions 
Architect Architect 


The Operations Specialist executes 
day-to-day technology operations 

‘ \ (functional maintenance), monitors 
technology operations, performs 
Problem Management, manages 


~ The Infrastructure Engineer* 
Common Core services configures, maintains and monitors the 


; provisioned infrastructure that is hosting 
ener the application (full-stack responsibility) 


The Scrum Master facilitates the 


change processes (Approves/Rejects) 
Infrastructure functions* Peron pe See & approach, 
manages impediments and 


4 *The scope of infrastructure engineer role depends on enables continuous improvement 
the maturity of the shared infrastructure function. 
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Different team topologies 


ooo 


ann 


No one-size-fits-all approach, DevOps can be implemented in many different 
organizational and team setups 


DevOps team with an expiry 
date 


Temporarily setup DevOps team 
as separate entity to existing 
Dev and Ops Teams 


2 Dev and Ops collaboration 


Enables collaboration and co- 

creation between Dev and Ops 
through a common vision and 

shared responsibilities 


3 Fully shared Ops 
responsibilities 


Fully integrated DevOps team 
with shared goal and 
responsibilities 


4 DevOps as an external 
service 


DevOps team supporting smaller 
Dev teams 
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© Development team 


As an organizational 
pilot or hybrid state 
for organizations 
aiming to adopt 
DevOps 


To move away from an 
“us vs them” mindset. 
(NB: the extent of 
overlap depends 
mainly on organization 
size and resource 
resources) 


Works best for 
organizations with a 
single main product or 
service 


Organizations with 
limited operational 
issues, DevOps team 
focusses on 
supporting dev teams 
in the problem 
domains 


. DevOps team 


5 Ops as infrastructure-as-a- 
service 


Infrastructure operations are 
fully covered in the self-service 
model consumed by the DevOps 
team 


6 DevOps Evangelists Team 


Team setup facilitates 
communication between Dev and 
Ops teams while keeping the 
majority of the existing team 
setup 


7 Separated responsibilities for 
regulated industries 


Separate responsibility for Dev 
and Ops on the DevOps team in 
order to provide an auditable 
trail 


OO Operations team 


Traditional 
organizations with 
several products or 
services in which the 
Ops teams provides 
IaaS 


When the organization 
is reluctant to change, 
this setup could be 
used to slowly 
transitions towards a 
DevOps organization 


When organizations 
report to external 
supervisory bodies to 
comply with industry 
regulations 
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T-shaped profiles ifs 


Ideally, DevOps team members have a T-shaped profile, teams have a combination of 
different profiles covering all knowledge and skills areas 


Knowledge Areas* Skills Areas* 


OO 


Why we advise T-shaped profiles 


A T-shaped profile entails that a team member covers 
different knowledge areas and skills in varying levels 
of expertise. 


Optimization 
Business 
Analysis 

Architecture & 
Design 
Programming 
Continuous 
Delivery 
Test 
Specification 
Infrastructure 
Engineering 
Security, Risk & 
Compliance 
Teambuilding 
DevOps 
Leadership 
Continuous 
improvement 


o 
= 
fe 
> 
w 
wn 
oO 
= 
a 
3 
co 


A team with T-shaped profiles does not have a 
hierarchy since everyone’s skills and knowledge 
complement each other. 


B A lack of hierarchy brings a team closer together and 
- creates a sense of shared ownership. 


Level 1 — Novice [ Level 2 — Competent il Level 3 — Proficient Level 4 — Expert Level 5 — Master 


Level 


Strict obedience to rules, no Still limited with situational Sets priorities, actions are seen Perceives deviations from the Has a wealth of experience, 
experience, little situational perception, knows the aspect partly in longer term goals, normal patterns, makes decisions creative solutions and visions, 
perception, no discretionary guidelines and treats all attributes deliberate planning, standardized more easily, assesses situations as breaks the rules when needed, 
judgement and aspects separately, yet equally procedures part of the “big picture” uses analytic approaches 


sparingly, makes good decisions 
quickly yet professionally 
*DevOps Agile Skills Association (DASA) 
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The mindset of a DevOps team member ARR 


DevOps team members foster certain cultural aspects contributing to the end-to-end 
ownership of services 


A mindset of effectiveness 

We continuously improve our delivery to improve our 
effectiveness. We define effectiveness as our ability to adapt 
to “market” circumstances and the success (value) of the 
product features delivered. Note that this also includes the 
effectiveness of activities, such as backlog prioritization 


Inspirational and fun environment 
An environment in which people perform at best, 

where they feel inspired, where they want to be, 

feel welcomed and are encouraged to think out of 
the box 


_— Continuous learning & 
Continuous improvement 


We have the desire to explore and learn in all 
activities we do. We strongly believe that working 
together, transparency, and sharing knowledge is 
vital. We care about our job enough to not pass the 
buck, we want to learn all the parts as a whole and 
not just our little world 


A mindset of taking responsibility 
All members of our team are responsible for the 
complete product, which includes the full 
delivery cycle as well as operating/providing 
customer support throughout the lifecycle of the 
product in a collaborative mindset 


An engineering mindset 

We have the desire to utilize our knowledge, 
skills, and creativity to solve problems, implement 
product features, and optimize our delivery 
process. We do not settle for the current status 
quo. We strive to improve our craftsmanship 


Experimentation & Risk taking 

We always conduct experimentation using solid 
methodologies to ensure ideas are evaluated on 
the real value instead of the assumed value 


Build quality in 
Quality is built-in from the initiation of the 
teams up to discharge. It is at the heart of 


every activity. It is never compromised. We 
value full transparency 
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A mindset of product thinking 

Our application is our product. It must deliver 
value when it runs in production. We need 
continuous improvements to ensure the 
application delivers value now and in the future 


Factors influencing DevOps organization design 


=bo 
— me -) 
=oe 


DevOps theory doesn’t always apply to practice, client specific factors need to be 
taken into account for an applicable and effective DevOps organization design 


Existing 
organizational 
Structure 


Regulatory 
Requirements 


Process & 
Archi- 
tecture 


Client specific factors to be 
taken into account for an 
DevOps organization design 


Resource 
Capacity 


Business 
Needs 


Product 
Varieties 


Sourcing 
Model 
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DevOps organization design is client specific 


Setting up DevOps teams or an entire DevOps 
organization requires understanding of existing, but also 
future organizational structures. 


Client specific factors might increase the complexity and 
effort that is required to transform towards a DevOps 
organization. 


|” 


There is no “one-size-fits-all” DevOps organization 
design. Client specific factors must be taken into 
account. 


Example considerations for an effective “to-be” DevOps 
organization design are: 


* Keeping some functional hierarchy intact to 
facilitate collaboration with the enterprise 


¢ Re-architecting the technology stack to enable 
DevOps practices 


« Adhering to some degree of separation of duties to 
comply with regulations 
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Process 
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The DevOps model is significantly different from the traditional IT model 
DevOps integrates the application lifecycle into an end-to-end, iterative process 


Traditional IT Model Implications 


« Straightforward sequential process 
assuming all is known 


Define Design Develop 


App 
Dev 


« Big chunks of work 


« Maximizes each process-step, big- 
bang delivery 


« Many separated functions (silos) 


Release & Operate with (manual) handoffs 
Deploy 


Infra & 


« Specialization (I-shaped roles) 
« Rigid change ability 


Implications 


= Complex iterative process to 
manage unknowns 


» Small chunks of work 

« Maximizes flow, incremental delivery 
Continuous Continuous Continuous 

Integration Testing Operations = Fewer handoffs (less silos) 

= Generalists (T-shaped roles) 


« More flexible to adapt to change 


Continuous Improvement 
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DevOps leverages technologies to automate the software delivery process 


While extending agile, DevOps optimizes the software delivery process by leveraging 
CI/CD which automatically promotes developer’s source code to operational solutions 


Everything in Version Control - Versioning ensures that no work gets overwritten and that the latest versions are built upon 


DevOps 
Software A 
Delivery 
Process Requirement & Source & Release & ; 
Ideation Design Develop Deploy Operate Monitor 
(ae ei i ee iia Y.-S ae A.-f iia A. -f- ee act a_i ear ae og ae ay 
, Continuous Continuous Continuous Continuous , 
\ DevOps extends the Agile Integration Testing Delivery Operations j 
DevOps \ Process and puts emphasis ... its practices focus on bridging the stage gate gaps between phases to | 
Practices \ on the software delivery cycle accelerate throughput by promoting more frequently with smaller products... / 
\ and operations... j 
7 ... next to this, DevOps practices incorporate feedback loops continuously in / 
\ the process for value creation and learning by experience ’ 
qe el oe i ae el Soe OS, ae ee oe a ee lee no ene oe eee Lae a ee oe | 
| CI/CD pipelines integrate process into technology 
[ 
| Automates almost everything - Automation drastically reduces time, effort, and risk of human errors 
The | 
CI/CD Done means released - Deliver releases for pre-deployment or deploy new releases to productions in minutes instead of months 
snali | 
Pipeline 
l 
I 
l 
l 


Builds Quality Into the Process — The quality of every deliverable is guaranteed errors and problems are detected early 
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Technology 
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A legion of tools are available to support DevOps practices 


As DevOps is a tool intensive practice, a thorough tool selection incorporating client 
maturity is a crucial part of the DevOps transformation 


PERIODIC TABLE OF DEVOPS TOOLS (v3) 


[os Open Source 
[Fe Free 
[Fm Freemium 


[Pa Pais 


En Enterprise 


DevOps is a tool intensive practice 


The voluminous amount of tools available, delivering one or 
multiple capabilities brings consequences when transforming 
towards a DevOps organization 


° Selecting the right tools requires an iterative approach 
(a procedure per capability) 

° Selection is, among others, based on engineering 
skills, prior experience, or tools (architecture) already 
in place 


cy XebiaLabs 


ss Ds, 


XebiaLabs published A sample selection of DevOps tools categorized in capabilities — 


Source: https://xebialabs.com/periodic-table-of-devops-tools/ 
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Patterns to setup a CI/CD pipeline 


Selecting the right set of tools (Best-of-Suite, Best-of-Breed or hybrid) for the CI/CD 
pipeline depends heavily on IT maturity and tech-savviness of the organization 


Applicability of the toolset Best-of-Breed 


“Selecting the best product of its kind” 


Hybrid 


“Best of both worlds” 


Advantages 


2 ¢ Flexibility - you are not depending ona 
Best-of-Suite one-size-fits-all solution1 
“Bundle of end-to-end enterprise 


software applications” 


Advantages 


Independent - you can pick and choose 
new capabilities regardless of the core 
solution 


* Quality cascade - 
iterate upon the current 
setup and consider best 
option available 


Advantages Disadvantages Disadvantages 


* Control - one central ¢ Standard solution — Often a 
place to manage users, bit more rigid than best-of- 
applications etc. breed solutions, offering * Effort to determine 

less room for specialization concurrent tools - The 

hybrid approach 
considered a thorough 
reconsideration for 

One integrated every requirement 

platform to process the between Best of Breed 

pipeline from Integration focus - New and Suite 
features have the objective 
to integrate with the core 
instead of being the best of 
its kind 


¢« Maintenance - requires knowledge of the 
setup of each, and dependencies between 
applications 


Disadvantages 


User experience - one 
similar user interface Partner dependency - The 
for the pipeline performance and 
development of the features 
depend on a single provider 


« Vendor segregation - issue solving might 
cover multiple vendors with different 
support models 


Tech-savviness 
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A basic functional flow through a CI/CD pipeline 


A CI/CD Pipeline can be build in various ways considering the desired tooling patterns, 
covering the same functional flow with different tools and integrations between them 


Source & Develop Build & Test Release & Deploy Operate & Monitor 


Distributed source code repository and 
version control system manages code 
changes during software development 


Build and test automation process the 
application code based on the latest 
changes in the source code repository 


Central repository manages and 
versions the released application 
artifacts and dependencies 


Monitoring the performance of the team 
in the software delivery process using 
DevOps metrics and KPIs 


Source Code Repository Code Build and , : 
ad : or 
and Version Control Automated Testing Artifact Repository 


Agile Planning and Test Strategy, Execution : 
Collaboration and Reporting Automated Deployment Software Operations 


oftware Delivery Process 


Collaboration environment supports 
the delivery process and planning of 
the DevOps Teams 


Test repository manages test 
strategies, test cases, test execution 
and reporting of test results 


Deployment automation deploys the 
released application artifacts and 
dependencies to target environments 


Monitoring of the deployed system’s 
health & performance using application 
and infrastructure monitors 


Best-of-Suite 


Best-of-Breed 


v 
I, 
>splunk> cucumber” 


Only a few interfaces are required as Atlassian’s 
suite covers the majority of required functionality 


Azure DevOps covers the full extent of the CI/CD 
pipeline, with no external integration required 


The pipeline orchestrator (Jenkins) becomes the 
central component to integrate all applications 


——~ Same suite, no interface ; : : 
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DevOps and Cloud go hand-in-hand 


The DevOps way-of-working makes instrumental use of cloud automation. However, 
DevOps practices can also be applied in hybrid or on-premise environments 


DevOps is accelerated using automation principles that are applied in the 
Cloud. DevOps methods and tools require a platform that is able to change 
quickly. Due to the agile and self-service nature of cloud, DevOps teams can 
collaborate on a single platform, in which they can source & develop, test 
and deploy new functionalities without the burden of underlying 
infrastructure. 


Continuous 
Delivery 


Continuous 
Testing 


Continuous 
Integration 


Continuous @® 
Operations 
Solution 


| 


On-premise environments increases the scope of the DevOps teams. 
Fortunately, DevOps practices are not environment specific and the DevOps 
| teams can add team members with skills required to develop and operate 

| the on-premise infrastructure. 
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Operating Model 
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DevOps Target Operating Model (TOM) © 


The DevOps TOM aims to land the DevOps way-of-working in the organization by 
describing the DevOps practices using Deloitte’s framework ‘Technology TOM in a box’ 


’ The Technology TOM in a box is an holistic framework to 
Technology TOM in a box describe the governance structure of an technology 
organization and how it functions as an entity 


. The capabilities of the DevOps practices will be described 
STENT IS | IETSUTS IS through the dimensions of the Technology TOM in a box 


The DevOps Target Operating Model (TOM) outlines the 
governance structures on how an organization should govern 
and operate the DevOps practices 
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Governance through a DevOps TOM 2) 


We use the DevOps TOM to explain to a client how it should Organize, Execute and 
Behave in a DevOps world 


DevOps TOM The Technology TOM describes a number of inter-related dimensions that reflect how 
a Technology organization is Organized, how it Executes and how it Behaves 


Using a number of inter-related dimensions we 
explained to the client: 


od 
© 
I ; I ] j S fe 
1. What services the organization is going to = 


deliver, and to whom 
Cc biliti Metrics & 
2. How these services are delivered using 5 


tooling 


3. Where these DevOps capabilities are sourced a colpboration 
from, what the ecosystem looks like, and how 
Oo izati G I ti & 
|, 
c= 


to collaborate in a DevOps culture 
4, Who are responsible for service delivery and = as 
support using DevOps roles and organization 


structure 
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Detailing the DevOps practices 2) 
The DevOps TOM describes capabilities that are part of the DevOps practices 


Organization (®) [| f [ [| 
Ss 


Continuous Continuous Continuous Continuous 


Integration [J Testing «= oeelivery = Operations 


Test Automation Telemetry & Logging 
Test Environments & Data Metrics / Dashboards 
Bug Reporting & Defect Management Self-Service Portals 
DevOps System Architecture pate Secunky Release Orchestration Pine Spots 
capabilities Development Practices Deployment Automation 
(non-exhaustive) Development Environments Configuration & Asset Management 
Source Code & Version Control Environment Management 
Automated Code Build Infrastructure automation 


CI/CD Metrics and Tracking 


© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 35 


DevOps operating model differentiators 2) 


The DevOps way-of-working has several implications on the operating model that 
differentiates from traditional operations 


Differentiators of the DevOps TOM 


Organize 


Impact: 


« Service Oriented Organization: 
Resources organized around services, 
focused on delivering designated 
business outcomes 


Organize the People: Creating high 
performing teams working focusing on 
a common goal 


Venture-Capital style Budgeting: 
Funding dependent on minimal viable 
product, and its performance 


Organize the Work: Slicing the work 
into smaller chunks that add value to 
customers immediately and then 
investing in it 


Sourcing Model: Sourcing model 
aligned to need of firm based on 
additional capabilities and delivery 
methodologies introduced 
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Impact: 


* Redefined Roles & 
Responsibilities: Redefined 
managerial roles, integrated within 
self-organizing scrum teams 


Iterative and Frequent Releases: 
Introduction of DevOps practices for 
iterative and frequent releases 


Speed Up the Work: Providing tools 
and automating processes to minimize 
handoffs and maximizes checkpoints 
to reduce dependencies and risk 


Improved Interaction: Siloes 
broken down between and within the 
business units and IT organization 


Impact: 


Structured Vision: Vision adapted to 
changing business needs of the 
business and customers 


Collaborative Services & 
Capabilities: Increase in usage of 
collaborative services and capabilities 
to the support business expectation 


Visibility and Transparency: 
Greater visibility and transparency 
across the firm with merging of 
development and support functions 
and capabilities 


Cross functional Team: Resources 
formed from Run, Change, Design, 
and Test, to focus on specific product 
or service which needs to be delivered 
to customer or business 


Source: Deloitte Technology TOM in a box 
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How do I implement DevOps? 


Option 1: Standard Deloitte transformation approach 


The DevOps transformation journey across a large organization takes 2-3 years, but 
starts with a clear Alignment & Vision created in 8-10 weeks 


proach 


-on AD 
Deloitte transformation 


Standard 


Do we have a 


Adopt 


Pilot 


Have we rolled 


holistic view of Do we have a sense of what “good” is out new 
issues and like? capabilities to 
options? key areas? 


Alignment/ Vision Pilot MVP/Targeted Assistance Adopt/Implementation 


Help articulate the vision, execution Select a pilot to build a MVP with a CI/CD Establish Nerve Center/Center of 
plan and funding requirements in a pipeline to establish a model for rapidly Excellence for scaling DevOps capability. 
short sprint. identifying and launching projects to 

propagate DevOps thinking into practice Typically done in a Build Operate Transfer 
Deloitte team leads with sponsorship | quickly across organization. (BOT) model. 


and co-leadership from client team. 


Deloitte acts as facilitator and starts the 
transition as the client takes on a more 
coaching/managing role. 


8-10 weeks 8-12 weeks 18-24 months 


© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 


Option 2: Co-created transformation 


A future vision stays the basis for the DevOps TOM, but for delivery we can shift 
towards a bottom-up approach and co-create change iteratively with the client 


Alignment / Vision 


Phase 


Iteration 


Operating Model 
dimension(s) 


Imagine the future of services in the 
service organization (dot on the 
horizon): 


* What is the mission of service 
organization? 


¢« What IT services, and to whom, is the 
service organization going to deliver? 
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Co-created transformation 


Implement Improve 


Define 


What 


Ca Se 
om cm 4ow 


Where Gill (ill Om 
Who [=o 


Co-create the DevOps Operating Model iteratively using 
a combined Deloitte client project team: 


Each iteration defines and implements a prioritized set 
of DevOps capabilities based on the delivery of CI/CD 
pipeline technology 


Scope is determined prior to each sprint based on: 
1. Actual CI/CD pipeline technology delivered 
2. Relevant Technology TOM in a box dimensions 


Collaboration with the client: 
1. Full support and dedication of DevOps champions 
(dedicated client project team members) 
2. 2-wk alignment with internal client stakeholders 


Eo) ~=What 


How 


Where | 


a Oe 
Who ga On 


Scale the DevOps Operating Model and 
technology within the client organization 
depending on the transformation need. 


Establish Nerve Center/Center of 
Excellence for scaling DevOps capability. 
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What are the challenges of implementing DevOps? 


DevOps majorly challenges skills of everyone involved: management and team. It may 
lead to development slowdown and will not compensate for lack of responsibility 


1. Skill Challenge: Keeping pace with the required skills may challenge your team 

2. Scarce talent: Some special skills in your organization can’t be replicated for every DevOps team 
3. No magic: DevOps will not compensate for potential lack of responsibility in your organization 

4. Lack of Overview: Progress and stability are spread across the teams and overview may lack 

5. Dev Slowdown: Operations may hamper progress in development 

6. Self-organization Challenge: Clear Service-Level Structures in operations may be challenging 


7. Management Challenge: DevOps can mean management challenges for your team leads 
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Key Lessons Learned 


During our engagements we gathered the following key takeaways that we will bring 
to future projects 


You cannot “buy DevOps” Management support is crucial Break down silos Assign champions from client 


ane DevOps adoption cannot be bought and Management involvement is crucial in Break down silos. Not only between Ensuring the support of the client can 
“bolted on” the existing organization. It | the DevOps transformation, as change departments, but also between be accelerated by having a champion 

And requires a cultural shift around how starts and stops with them organizations from their side spreading the DevOps 
people deliver their work culture and principles 

| Process Consider secondary impacts Collaboration is key DevOps # Agile Focus on E2E responsibility 
Product roadmaps will be impacted and DevOps requires close collaboration DevOps can be seen as an extension of — Limit handovers as much as possible, 
{0} delivery bottlenecks reduced. New across dev, test, operations and Agile, with the same level of agility teams must adopt an end-to-end 

{0} budget to build a DevOps organization business teams to effectively deliver driven into development, test and responsibility for the product or service 

will be needed value to the organization operations they deliver 
Technology Modern architecture is critical Show value quickly DevOps # Automation Use Cloud as an accelerator 
Platforms built on modern architectures ‘Prove’ the DevOps concept by Release and Deployment Automation or Ensure parity between cloud and on- 
based on modular design, decoupling demonstrating working solutions early App Release Automation are only a part premise implementations (e.g. Azure 
and good componentization enables and often (e.g. CI/CD tooling) of DevOps. End-to-end automation is DevOps) 
deeper adoption of DevOps key 
SIL, Collaborate with Tech Stream Change incrementally DevOps # Organization 2S MORTARS TE) GLH 

Model specific 
Design the DevOps operating model in Apply an agile approach for adopting There are different organizational DevOps target operating model 
parallel and close collaboration with the © DevOps and introduce change patterns to setting up DevOps and it transformation depends heavily on 
technology implementation incrementally with focus on the doesn't always have to be making ita where the client is in their DevOps 

outcomes separate organization journey 
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Deloitte Accelerators 


Deloitte DevOps Maturity Assessment Offerings 


To understand the current state DevOps capabilities and to identify areas for 
improvement, we have two assessment methodologies available. 


CIDORA 


DEVOPS RESEARCH & ASSESSMENT 


DORA provides a SaaS questionnaire that benchmarks DevOps 
performance against 2000+ leading Enterprises across industries 


« “Gold standard” for DevOps assessments 
= Compare your results against others in industry 


= Two assessments included - one to baseline and one to measure 
progress 


Benefits 


« Provides priorities for capability improvement 


Deloitte receives a 30% discount from DORA; will be an additional 
cost on top of pilots 


~ 
1) 
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w Industry Capability 
Benchmark Prioritization 
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Deloitte’s DevOps Maturity Assessment (DDMA) is an extensive 
questionnaire for assessing current state against desired future state 
maturity of DevOps capabilities across the DevOps domains: from 
Release Planning to Continuous Deployment and Monitoring. 


* 180 questions along each of the DevOps domains (Release 
Planning, Continuous Development, Continuous Integration, 
Continuous Testing, Continuous Deployment, Continuous 
Monitoring) 


« Assesses maturity against desired future state 


« Identifies areas for capability improvement 


Included in price of DevOps KickStart or DevOps Dojo 


Continuous Integration 
Maturity Maturity 


Release Planning 
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Deloitte Global Accelerators 


Our Global DevOps Community of Practice has a wide variety of accelerators available 


that we can use in our engagements 


Learning 


Learning Series 


Basic introduction course 
to various DevOps practices 


Learning Resources 


A collection of documents to assist 
learning DevOps and specific 
elements or specific vendors 


Videos & Demos 


A collection of videos and demos 
regarding Deloitte methodologies 
and instructions for DevOps 
tooling 


Sales Materials 


Proposal templates & DevOps 
brochures 


Templates & brochure to help you 
kickstart your DevOps proposal 


DevOps Qualifications 


‘Quals’ to help you display 
Deloitte’s capability to deliver 
DevOps transformations, including 
tooling 


DevOps Case studies 


Case studies of client 
engagements, with success stories 
and demos. The Client demo can 
showcase DevOps automation 
capabilities 


Note: non-exhaustive, Global examples, which may be updated continuously 
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Tools and Enablers 


DevOps Local toolkit 


An integrated toolkit of local 
DevOps tools to gain hands-on 
experiences 


Deloitte supplied tools 


Tools that can be supplied for 


client engagements: 
* Agile Manager 

HP Application Lifecycle Management 

Fortify 

JRebel 

Performance Center 

SonarQube 

Unified Functional Testing and UFT Pro 


Enablers 


Enabling materials for specific 
vendors, industries, such as the 
Cloud Compass, PoC for SAP or 
Google Cloud enablers, Cards for 
Agility, Technology TOM in a Box 


Eminence and Point of Views 


Eminence 


Examples of Deloitte DevOps 
materials published in popular 
media 


DevOps Point of Views (PoV) 
¢ Cloud platforms 

* Collaboration tools 

* Development suite tools 

¢ Software Build tools 

* Software Deployment tools 

* Container persistence 

* DevSecOps 
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Client example 1 


DevOps journey and CI/CD 
pipeline implementation 


Deloitte DevOps Point of View 


Client example 1: Global parcel delivery services company 


We took our client on a DevOps transformation journey across all five dimensions to 
streamline the software delivery lifecycle of their mission critical system 


Process 


Develop a chain of full end-to-end _~ 


processes to facilitate the DevOps way-of- 


Technology 


From requirements, to tool selection, architecture 
design and full implementation; we built a CI/CD 


working and continuous software delivery {6} pipeline base on MS Azure DevOps to enable 
* Described CI/CD processes to operate {B} continuous integration and continuous delivery 
the pipeline through all DevOps « Automated as much as possible, while 


practices 

* Implemented continuous feedback 
loops into process flows to facilitate 
continuous improvement 

* Defined and implemented auxiliary 
processes to support and smoothen the 
execution of the DevOps lifecycle Operating Model 


maintaining stage gates for deploying to 
mission critical environments 

* Supported persistent configuration 
management to deliver tailored software to 
distributed, distinct production systems 


Designed and implemented a 
governance structure to 
successfully have business- 


Organization & Culture and value-driven DevOps 


; : teams that take full ownership 
Designed and implemented a fully fledged 


bane H of their product/service, 
DevOps organization, along with teams including: 


covering the full lifecycle of services, as well Pe eeninecanectarect Data 
- . Te e . . . . 
as defining a culture to facilitate Ann aise ast oath Obtain as much insight, by logging all data 
Operating Model 


collaboration, knowledge sharing and 

continuous improvement 

* T-shaped role descriptions for team 
members 

* Described ways-of-working to enhance 
visibility and feedback 

* Defined a culture based on CALMR 
principles, with accompanying metrics to 
enhance adoption 


and monitoring relevant metrics, by 

employing DataOps 

¢ Gather data from CI/CD process 

¢ Infrastructure logging & monitoring of 
develop, test and production environments 

* Operational data logging, monitoring and 
analytics on operational process execution 

¢ Provide dashboards to view and report on 
performance 
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Client example 2 


A CI/CD Pipeline for a Banking 
Platform 
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Client example 2: CI/CD pipeline 


Deloitte developed an Open Banking Platform as a global asset with an CI/CD pipeline 
to ensures continuous integration and deployment 


Bg Buildkite | 8uic & Deployment Security & 


Quality Control 


</> J Y ae >» 
ee sonarqube \ —— “@. Nexus 


Local Unit tests, static code 
Development Code Repository (GIT) checks, code smells Repository Management 


Check if the repositories 


Secure coding 


Code review & Security checks & 


used are whitelisted (only 
approved software) 


guidelines & 
Training 


Source code 


Security checks 
validation 


Controlled deployment to 
production & testing 
environment based on 
agreed release candidate 


aa aw ss 


Se —_a > 

_, kubernetes 7 
docker — Oy 
Microservice is packaged in Docker Amazon ECR handles the Container is deployed . 
container and published to container container registry to the platform 


An image scan is performed to Validation of security 
detect known vulnerabilities baseline 


Image is hardened and 


checked if in accordance 
with security baseline 


Secrets Management Container is immutable 


Fuzz testing, Pentesting & 
Vulnerability scans 


© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 48 


Client Example 3 


Test Automation for a Banking 
Application 
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Client example 3: Automating End-to-End Testing 


We helped our customer to setup their testing capability, a vital but time-consuming 
part of the software delivery process 


Customer aims to speed up release and ensure software 
SOFTWARE VENDORS quality through UI-based E2E Integration and Acceptance 


, testing with the Selenium Framework 


; Requirement & Build & Operate & 
Ideation Design Develop Deploy Ls» Release Monitor 


—_ SA 


CUSTOMER CUSTOMER 


Tetrrese ET ee ee ee ee 


System tests Deployment tests * Deployment tests * Non-functional tests 
. oe eet * Integration tests based on * Business Acceptance : fee 
Type of tests g user stories Regression tests (E2E) Y 
7 ¢ Disaster Recovery 
Deployment tests 7 


megnesslon: tests (E25) Prepare for go-live execution 
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Client example 3: Automating End-to-End Testing 
Using a test automation framework based on Selenium, Deloitte delivered a total of 15 


automated end-to-end test cases 


Requirement & 


Design Develop 


Ideation 


@ 
cucumber 


Behavior-Driven 


Development 
Given I navigate to “Deloitte.com” 


And I click “About Deloitte” 
Then I should see title “About us” 


& Java @Bitbucket 


—=~+ 
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Operate & 
Monitor 


Fs 
Jenkins 


CI/CD Automation Server 


Web Browser Automation 
Framework 


Build Automation Tool 


Trigger test run based on 
« Time 

¢ Code commit 

¢ JIRA update 
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Recommended resources 
In case you got excited and would like to learn more... 


Books: 
¢ The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations 
— by Gene Kim, John Willis, Patrick Debois, Jez Humble 


¢ The Phoenix Project 
— by Gene Kim, Kevin Behr, George Spafford 


¢ Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation 
— by Jez Humble and David Farley 


¢ Accelerate: Building and Scaling High Performing Technology Organizations 
— by Nicole Forsgren, Jez Humble, Gene Kim 


Websites: 
¢ https://notafactoryanymore.com 


Video's: 
¢ John Smart (Deloitte colleague) at the DevOps Summit: https://www.youtube.com/watch?v=-Rq-fuiKNCU 
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